Hello everyone! I'm new here, and I'm very intrigued by this PR

I'm very far from C++, and unfortunately, I'm more familiar with Java :(

I looked at the code and wanted to suggest implementing a common interface and then using it to implement resource handlers, like animation/sound and so on, depending on the game. If it is possible to implement it

Here's the idea:

During the game's initialization or launch, determine the game type and use it to call the necessary code

GameType:
   CS, COP -> UnifiedResourceDispatcher
   SOC -> SocResourceDispatcher

class UnifiedResourceDispatcher : public GameTypeSpecificResourceDispatcher {
    // Interface contract implementation
};

class SocResourceDispatcher : public GameTypeSpecificResourceDispatcher {
    // Interface contract implementation
};

The set and names of the methods/classes defining the contract are the same, but the implementation is specific to a given type of game

It seems to me that this solution will simplify the code and reduce computational costs when checking conditions (I'm not sure that the branch predictor will always work correctly)

UPD:
I didn't initially see that the conditions for animations and other things, like config, are set in the lower-level classes.

Based on these considerations, I can suggest next ways to solve this issue:

1. Dividing resources by game type using interfaces, where, similar to the resource dispatcher, each game type will have its own implementation (this option doesn't seem very appealing to me)
2. Build objects based on external configuration by class constructor (this is where the resource dispatcher can be useful)
3. Or (the longest and most boring, but maybe most right way) - bring the game resources up to the CS/COP standard

Hello everyone! I'm new here, and I'm very intrigued by this PR

I'm very far from C++, and unfortunately, I'm more familiar with Java :(

I looked at the code and wanted to suggest implementing a common interface and then using it to implement resource handlers, like animation/sound and so on, depending on the game. If it is possible to implement it

Here's the idea:

During the game's initialization or launch, determine the game type and use it to call the necessary code

GameType:
   CS, COP -> UnifiedResourceDispatcher
   SOC -> SocResourceDispatcher

class UnifiedResourceDispatcher : public GameTypeSpecificResourceDispatcher {
    // Interface contract implementation
};

class SocResourceDispatcher : public GameTypeSpecificResourceDispatcher {
    // Interface contract implementation
};

The set and names of the methods/classes defining the contract are the same, but the implementation is specific to a given type of game

It seems to me that this solution will simplify the code and reduce computational costs when checking conditions (I'm not sure that the branch predictor will always work correctly)

UPD: I didn't initially see that the conditions for animations and other things, like config, are set in the lower-level classes.

Based on these considerations, I can suggest next ways to solve this issue:

1. Dividing resources by game type using interfaces, where, similar to the resource dispatcher, each game type will have its own implementation (this option doesn't seem very appealing to me)
2. Build objects based on external configuration by class constructor (this is where the resource dispatcher can be useful)
3. Or (the longest and most boring, but maybe most right way) - bring the game resources up to the CS/COP standard

interesting idea